Debugging

It will become apparent to you many times during a program's evolution that the program is not entirely right. Instead of blaming the program for these faults, strange creatures called bugs are blamed. In this way, the programmer remains free of guilt. Errors and incorrect results are sure signs that bugs lurk inside a program, for the bugs cause the aberrant behavior.

Debugging usually depends on empirical testing, thus it can serve to reinforce the programmer's belief in the correctness of his program, and it can aid in correction of a program which is not behaving as expected, but it cannot prove that the program is correct. If the program succeeds during debugging, there may be some yet-to-be-uncovered bug lurking within, waiting to show itself in some later run. The best protection against program bugs is a program that is well thought out and clearly set down in code.

Scheme provides several features to aid in debugging programs. Among these are the ability to trace the execution of a procedure, the ability to examine the current environment, and the ability to set breakpoints. From a breakpoint, you can examine the recent process history of your program.

Bugs are sometimes detected by the occurrence of an error while the program is running. When Scheme encounters an error, execution is abruptly halted, you are notified, and you are given thechoice of either aborting from the error, or entering an error read-eval-print-loop. (See section $[*]$ ). Here is a typical error response:
$\begin{scheme} (+ 1 'a) \par Illegal datum in second argument position A Within ... ...vironment available; using the current read-eval-print environment. \end{scheme}$

The error message—a concise description of the error—is the first thing printed. In this case, the error was a bad argument: the symbol a to the + procedure.

The error message is sometimes followed by information about the environment in which the error occurred. This is useful because the debugger includes some advanced features that allow you to probe or modify the environment. (See sections $[*]$ and $[*]$ .) Sometimes, as in the example above, the system will tell you that no environment was found at all, which means that you are in the environment of the previous REP loop.

If you choose not to abort, the mode line information (indicating Scheme's status) will change from
$\begin{scheme} I 1 \verb\vert[\vert REP Loop\verb\vert]\vert \end{scheme}$
to
$\begin{scheme} I 2 \verb\vert[\vert Error\verb\vert]\vert \end{scheme}$
to indicate that you are in an error REP loop. The number 2 signals that this REP loop is subordinate to a level 1 (top level) REP loop. See sections $[*]$ and $[*]$ for information on REP loops.

If you do choose to abort, you will return to the previous REP loop and you can try another expression. Beginning programmers have a tendency to automatically abort as soon as an error is encountered. This is unfortunate, because it destroys information about the error that can be used to aid in debugging. When you encounter an error, take some time to think about the error, rather than immediately aborting as a ``knee-jerk'' reaction.

Scheme provides system features that make use of the error environment in order to help you to try and locate where the error occurred. That is, you can see what expressions were being executed at the time of the error. The environment and history examiners, where and debug, respectively, are used for this. Of course, much can be determined about the state of the system at the time of the error by simply examining the values of variables in the error environment.

The program may run without error, but the result produced may be preposterous—another indication of bugs. For instance,
$\begin{scheme} (prime? 7) \ev \schfalse \end{scheme}$
In this situation, Scheme offers no clue as to the location of the bug—you're on your own. You might produce a theory about the cause of the deviant behavior and then test it using the trace facility. You can also edit the program to insert checks and traces.

Debugging, like programming, is an acquired skill and an art. The tools available to you are described in the sections below. Use them creatively. The laboratory assistants are there to help you. Feel free to ask them for help.

Subsections